工具裝好了，方向也想清楚了，安全繩也繫上了。照理說，已經可以開始動手了。
但在那之前，我想先花一天回答一個很基本、卻常常被跳過的問題：

一個網站，到底是由哪些東西組成的？

這件事跟「會不會寫程式」關係沒有到特別大，程式語言的某個語法怎麼寫可以交給 AI。但如果你連自己正在做的東西大概長什麼樣子都不清楚，就很難判斷一個功能該做在哪裡、哪些地方要特別小心，以及最重要的——自己做出來的東西安不安全。 安全性很麻煩，因為它不會跳任何錯誤訊息。有時候畫面一切正常、功能全部都能動，但卻可能被有心人士找出漏洞來取得一些敏感資料。

今天就是在補這塊底。

一、從一次點擊開始

假設你打開一個購物網站，在搜尋框輸入「無線耳機」，按下搜尋。從你的角度看，就是畫面跳了一下，結果出來了。

但實際上，這中間至少發生了四件事：

你的瀏覽器 把「我要找無線耳機」這個要求送出去 → 遠端有一台伺服器 收到這個要求 → 它去某個地方撈出 符合條件的商品 → 把結果送回來 ，瀏覽器再把它畫成你看到的畫面

這四個步驟，其實就對應到一個網站的幾個組成角色：

【圖 1｜網站的基本架構】

廣義來說，有些人也會將資料庫視為後端的一部分。

接下來，我們一個一個看它們在做什麼。

二、這些角色各自在做什麼

在開始之前，先給一個我覺得最好懂的比喻：餐廳 。（也是最多人用的比喻）

你在餐廳裡看得到菜單、餐廳的裝潢，但你不會走進廚房，也不會自己去倉庫拿食材。你只能透過畫計菜單、交給服務生，請廚房幫你做你想點的菜。

2.1 前端｜你看得到的那一半

前端就是跑在你瀏覽器畫面上你看得到的那一部分。
畫面長什麼樣、按鈕按下去有什麼反應、輸入框怎麼檢查、東西怎麼排版——這些都是前端。
它的工作主要是兩件事：把東西顯示出來，以及接收使用者的操作。

2.2 後端｜你看不到的那部分

後端通常跑在遠端的伺服器上， 它負責那些不適合、或不能在使用者電腦上做的事：

• 真正決定「這個人能不能看到這筆資料」
• 計算、驗證、跟其他服務溝通
• 決定什麼東西要存起來、怎麼存

你一般來說在瀏覽器裡看不到後端的程式碼。你只看得到它回傳給你的東西。

2.3 資料庫｜東西放在哪裡

資料庫是專門用來存放資料的地方。例如：商品清單、使用者帳號、訂單紀錄、專輯資訊 —— 這些東西要一直留著，而且要能快速找到，所以會放在資料庫裡，而不是寫死在程式碼裡面。

有些用 AI 快速做出來的網站，資料會不小心直接寫在前端程式碼裡。畫面看起來完全正常，但只要資料要更新、或是資料量變大，就會開始出問題。

2.4 API｜它們之間怎麼溝通

前端通常不會拿著資料庫帳號，直接連進資料庫。它會透過後端，或透過有權限控制的資料服務，去取得自己需要的資料，而這中間通常就會用到 API。以剛剛搜尋無線耳機的例子來說，正常的網站前端它要先跟後端說：「我要找無線耳機。」後端收到之後，才去資料庫查，然後把結果送回來，這個「說話的方式」，就是 API。

可以把 API 想像成不同程式或服務之間，事先約定好的溝通方式。

或回到餐廳的比喻：你不會(基本上也不能)直接走進廚房喊「我要一份義大利麵」，而是透過菜單。菜單上要寫什麼（例如大小份、辣度、數量）、怎麼寫（用打勾的、還是畫正字號）、廚房看得懂什麼格式 —— 這些都是事先講好的規則，而 API 就是那張菜單的規則。

而且很重要的一點：那張單子通常不是天上掉下來的，是你開店的時候自己設計的。 要有哪些欄位、哪些是必填、廚房做完之後要做什麼——全部都是你決定的。

網站也一樣。開發的時候，前端要怎麼跟後端要資料、要帶哪些條件、後端要回傳哪些東西，都是我們自己要決定的。而設計得好不好，會直接影響之後的網站安全性。後面會有幾篇文章專門處理這件事。

還有另一種 API：跟外面叫貨

你可能在別的地方聽過「串接 API」這個說法——那通常講的是另一件事。一間餐廳不會自己種菜、自己養雞。廚房遇到自己做不了的東西，會跟外面的供應商叫貨。而怎麼下訂單、對方回你什麼、要報哪個帳號，一樣是事先講好的規則。

網站也是。像收款、寄通知信、地圖定位、簡訊驗證碼這些，很少有人從零自己做——通常是找一個現成的服務，然後照著它規定的方式去呼叫。

所以 API 其實有兩種用法，只是都叫做API ：

這裡還有一個小地方，等一下會再提到：跟供應商叫貨用的那組帳號密碼，是廚房才有的東西。 你不會把它印在給客人的菜單上。我們這個專案之後也會用到幾個第三方服務，等技術選型之後會知道是哪些。

三、為什麼要分開？

到這裡你可能會想：搞這麼複雜幹嘛？全部寫在一起不是比較簡單嗎？

3.1 瀏覽器上顯示的東西，不是秘密

先做一個實驗。打開任何一個網站，按下 F12（Mac 可以按 Cmd + Option + I），你會看到一個開發者工具的面板。(也可以在網站上按右鍵 → 檢查)

【圖 2｜開發者工具面板】

你會看到一大串程式碼。點擊「Network」頁籤，重整後，也可以看到在載入這個網站過程中網站跟伺服器之間所有溝通的紀錄。每一筆都是這個網站跟伺服器之間的一次對話——送出去了什麼、收回來了什麼，全部在那裡。 而上面那張圖則是原始碼的分頁，你會看得到這個網站的前端程式碼。沒錯，任何人都看得到。

這不是因為那個網站沒做好，而是——前端本來就是這樣運作的。 瀏覽器要能把畫面畫出來，就必須先把那些程式碼和資料送到你的電腦上。

東西一旦送到使用者手上，就沒有秘密可言。
後續的文章會更近一步介紹開發者工具(DevTool)可以有哪些應用

3.2 所以，有些東西不能寫在點餐單上

回到餐廳。假設你的店有會員制度：報手機號碼就打八折。現在為了讓外場好查，你把所有會員的手機號碼印在點餐單背面 。外場確實變方便了——客人一報號碼，翻過來對一下就好。但問題是：那張單子是客人也看得到的。 任何一個來吃飯的人，翻過來就看得到所有會員的電話。你不會知道他有沒有看過，而前端就是那張點餐單。

所以有幾件事，不管看起來多方便，都不能放在那裡：

第一，鑰匙不能放在單子上。
有些服務會給你一組像密碼的東西，用來證明「這個請求是我發的」。如果它出現在前端，等於把店的鑰匙印在菜單上。

第二，不該給這個人看的資料，不要先送過去再藏起來。
有人會這樣做：資料全部送到瀏覽器，然後用程式判斷。例如：「這個人不是管理員，所以不要顯示」。但資料已經在他電腦上了。他不用按你的按鈕，直接打開開發者工具就看得到。在前端把東西藏起來，跟沒藏是一樣的。

第三，重要的檢查不能只做在前端。
前端的檢查是「幫使用者省麻煩」—— 少填一格馬上提醒他，不用等到送出去才知道。但它擋不住存心要繞過的人。因為那些程式碼跑在他的電腦上，他要改就能改。 就像你在點餐單上印「本餐點限會員」，但如果非會員點了這道餐，基本上得再確認過這個人到底是不是會員，才決定是否做這到菜。

3.3 而且，麻煩不會只從前門進來

一旦你的網站開始有人用，會遇到的狀況遠比「畫面對不對」複雜。

一樣用餐廳來想：

這些事情，在開發網站的過程中，會是需要去解決的。 因為前端在客人手上，而客人可以做任何事。真正能決定「這張單子要不要接、能不能做」的，只有廚房（後端）。

這幾件事我們不會今天處理——它們分別會在第三幕、第四幕中出現。但我希望你先知道一件事：

前端負責讓事情好用；後端負責讓事情安全。

四、一個功能，通常會同時牽扯到三層

講完角色，最後看一個實際的例子——這也是我們之後真的要做的東西。假設現在要做一個「搜尋專輯」的功能。它雖然只是設計一個可以搜尋的簡單功能，但它三層都會碰到：

這就是為什麼今天要先把這張架構圖弄清楚。因為之後每一個功能，在開始開發之前，可以先想清楚：這件事牽涉到哪些層面？

而我們接下來的順序會是：

• 第二幕（預計為 Day 6-14）：先做前端。畫面、互動、資料先用寫在前端中的模擬資料撐著
• 第三幕（預計為 Day 15-21）：再接後端和資料庫，讓資料變成真的，可以即時更新、編輯

先做看得見的那一半，是有理由的 —— 那會讓我們更早知道「到底需要哪些資料」。這件事後面會再展開。

結語與明日預告

今天沒有寫程式，但我們做了一件不複雜但很重要的事：釐清網站架構那幾個一直出現的名詞。

• 前端是使用者看得到的那一半，而且是幾乎全部看得到
• 後端是看不到、但真正在做決定的那一半
• 資料庫是東西存放的地方
• API 是它們之間溝通的規則

明天開始，我們會先從前端做起。

講到前端，你可能聽過 HTML、CSS、JavaScript，也可能聽過 React、Vue、Next.js 這些名字。它們是什麼關係？為什麼有這麼多種？我又是照什麼標準選的？

明天見。